Subject: The problem of the framework draft

From: Masataka Ohta <[email-masked]>
Date: Thu, 1 Jan 98 18:00:18 JST

Eric;

> There are more but I think I have belabored the point enough.  You can
> disagree that there are better technical approaches than Inter/Intra domain
> but the reality is that the current Internet is configured this way and no
> solution or approach can ignore it.

The basic problems of the current framework draft are that:

	The draft says some QoSR protocols have problems, which
	does not mean all the QoSR protocols have the same
	problems.

	The draft says some QoSR protocols have problems, and
	expect that some inter-domain QoSR can magically solves
	the problem.

	The draft does not show inter/intra domain separation
	possible.

	The draft does not specify the interface (if any, at all)
	between inter/intra domain QoSR, which makes many
	(if not all) intra domain QoSR can not interoperate
	with inter domain QoSR.

	The draft debates that the introduction of routing hierarchy is
	necessary and wrongly concludes that inter/intra domain
	separation necessary.

Any counter arguments?

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 1 Jan 98 17:48:44 JST

Eric;

> - Economics: Domain boundaries, both Intra and Inter, are necessary for the
> economic agreements in both the provider-to-provider and the
> provider-to-customer cases.

Economics has nothing to do with routing nor domain boudaries.

All you need for the economics is the natural boundary
between providers or between a provider and a customer or
between a sub-provider and a while-sale-provider.

But, the boundary exists and is useful for economic agreement
regardless of whether some protocol use inter/intra domain
separation or not.

With an algorithm without inter/intra domain separation, you can
put economic boudary anywhere in the Internet, which is just
necessary for the Internet today and in the future.

Merely a single layer of inter/intra domain separation is
no useful for the mult-layered economics of the REAL Internet.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 1 Jan 98 17:20:05 JST

Eric;

> - Scalability:  This is obvious.  Unless you have domain boundaries, there
> are no places to aggregate or summarize information, resulting in far too
> much information passed around.  This gets even worse when you add QoS
> information.

You completly misunderstand how the aggregation or summarization
of routing information is performed in the Internet today or in
the future.

Domains have nothing to do with the aggregation or summarization.

Today, CIDR is not so sucessful that the aggregation or
summarization are mostly performed on subnetwork and network (class
A, B and C) level boudary. With CIDR, additional aggregation
or summarization is performed on *ANY* router.

In the future, with IPv6, the aggregation or summarization is expected
to be done a lot better.

Anyway, there is several levels of the aggregation or summarization
at various points, from which domain boundaries are not actively
excluded, in the Internet.

> - Scalability:  This is obvious.  Unless you have domain boundaries, there
> are no places to aggregate or summarize information,

Domains contributes nothing for the aggregation or summarization.

It is so clearly obvious that no one carries subnet-wise routing
information all the way upto the domain boudaries.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 1 Jan 98 17:39:45 JST

Eric;

> - Deployment:  The Inter/Intra domain boundaries provide boundaries for
> incremental deployment of new protocols without "flag days".

Completely wrong.

The inter/intra domain separation makes the "flag days" necessary.

Unless two domains are ready for the intra-domain QoSR, which are
the flag days, you can't deploy an inter-domain QoSR.

On the other hand, intra-domain routing can be deployed
limitedly incrementally at any small portion within a domain but
not beyond a domain boundary.

Finally, protocols unrelated to inte/intra domain separation
can be deployed fully incrementally at nay small portion
of the Internet (even beyond domain boundaries).

That is, the inter/intra domain separation is harmful to
the incremental deployment.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 1 Jan 98 17:28:47 JST

Eric;

> - Security:  Domain boundaries provide a natural place to share only
> required information.  I doubt that many service providers are interested
> in showing the details of their internal routing structure, let alone
> resource information.

I share your doubt. But, the real reason not to advertise detailed
routing information is not in security but in scalability.

The amount of routing information does not scale with detailed
advertisement.

However, because the aggregation or the summarization are performed
everywhere in the Internet, your argument is irrelevant.

Finally, all the QoSR needs for service providers is aggregated transient
QoS information, unless the provider is the last or the first hop,
in which case, the necessary information is already available locally
and no advertisement to other providers is necessary.

So?

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 1 Jan 98 17:07:51 JST

Eric;

A happy new year.

> I disagree with some of the assumptions in your paper and your assertion
> that inter and intra domain separation is not a viable approach.

I'm glad to be able to begin the real discussion for the first
time in this mailing list.

> In your
> paper, you seem to assume that simple replacement of the current routing
> protocols with a QoSLSAP (QoS Link State Advertisement Protocol) is all
> that is needed to enable your algorithm for QoS Routing of only RSVP flows.
>  It is impossible to assume that any single routing algorithm or protocol
> can be deployed throughout the entire Internet.  The structure of the
> Internet into multiple routing domains and service providers necessitates
> separation of routing information for several reasons:

You misunderstand our paper.

You also misunderstand how the Internet is working.

In our paper, there is no requirement to have a specific QoSLSAP.

It is only required that the routing protocols carry QoS information
of links.

Distance vector QoS routing is precluded, becasue of scalability
consideration.

In addition to the reasons against DVQoSR, the strongest argument
agenst DV QoSR is that,

	DV is a distributed computation of a shortest path algorithm
	over all the routers in some area (or domain, region or anything).

	Each flow with different QoS requirement must notify its
	requirement for all the routers.

	The routers must, then, perform, shortest path computation
	flow by flow.

	Even if we enforce some small number of QoS classes, the computation
	must be prformed individually flow by flow, because the QoSed route
	computation is strongly stateful and may be different flow by flow,
	even if the QoS requirement is the same.

So, unlike wise LS QoSR approach which needs computation only on routers
on a selected path, DV QoSR does not scale.

It is not an excuse of the lack of the scalability of DV QoSR that
unwise LS QoSR (such as that of QOSPF) does not scale well.

Thus, DV QoSR is not a choice over the Internet.

Now, you can't force people in the Internet use RSVP.

At the same time, you can't develop ten variations of resource
reservation protocols, different for inter- and intra- domain
or between domains and simply expect them interopeate.

Just like that, we can't force the people use QoSR.

But, we should make QoSLSAP have uniform interface with RSVP.

> There are more but I think I have belabored the point enough.

No. Your are wrong. Details are explained in separate mails.

> You can

I am argueing that the approach in your draft is faulty and simply
does not work.

The current Internet with RSVP is based on the reality and is not faulty,
which is what you are ignoring.

That I have constructively shown a non-faulty approach is irrelevant
on the fault of your approach.

						Masataka Ohta

---

From: "Brian Edginton" <[email-masked]>
Date: Mon, 5 Jan 1998 11:23:10 -0700

>	necessary and wrongly concludes that inter/intra domain

Masataka,

 Ignoring the fact that there are some apparent inconsistencies in your
arguments and the fact that because of technical differences in the inter
vs. intra domain problem sets obviously different routing solutions have
developed over the years to address those differences, there exists
political
and corporate reasons that separation between inter/intra domain routing
solutions are and will remain necessary.

Brian Edginton
(forgive me for only one period in that string of characters)

						Masataka Ohta